1. Field of the Invention
The present invention relates generally to the World Wide Web (hereafter, “Web”). More particularly, the present invention relates to methods and systems for efficiently servicing requests for documents over a computer network.
2. Description of the Related Art
The Web has evolved from being a repository of static files (Hypertext Markup Language (HTML), Graphic Interchange Format (GIF) and the like) to a very dynamic system with Web sites that span the gamut of possibilities, from multi-media sites that broadcast music on demand to e-commerce Web sites linking consumers and businesses or businesses to other businesses. With this evolution in usage, there has been a corresponding change in the nature of the content served by Web sites. Indeed, an increasing number of Web pages served by Web sites, especially e-commerce Web sites and portals, are dynamically generated.
Generating Web pages on demand, in a dynamic fashion, is a very expensive operation, not only in terms of storage and processing time, but also ultimately in terms of money. The program or application logic that generates a dynamic Web page typically must access various data sources, user profile information and complex business rules to generate the Web page. Quite often, generating dynamic pages requires querying data from data-sources such as Relational databases (catalog information), or processing information feeds (like a stock quote feed, for example), which add to the cost of page generation.
There are various mechanisms for implementing application logic for generating dynamic Web pages. One such mechanism utilizes scripts (small embedded programs) based on Common Gateway Interface (CGI), which is a standard way for a Web server to pass a user request for a Web page to application logic and to receive the requested data back to forward to the user. The application logic can be implemented as a separate executable (Practical Extraction and Reporting Language (PERL-see http://www.perl.com) is one of the most popular languages for writing CGI scripts). CGI mechanisms, however, require a new process to be spawned for executing the application executable for each incoming request. Due to the overhead inherent in starting a new process for each request, this mechanism does not readily scale. As a result, Web sites have started looking for alternative mechanisms. Many high traffic Web sites now use mechanisms such as Servlets, JSPs and ASPs. Servlets are programs written in Sun Microsystems, Inc.'s Java language that execute on pooled, non-terminating processes and threads. This promotes highly efficient operation since new processes need not be spawned for each request. ASPs are Microsoft Corporation's Active Server Pages, a scripting facility that combines HTML scripts with embedded logic that can be developed in non-scripting languages for improved performance and functionality. JSPs are Sun Microsystems, Inc.'s Java Server Pages, a similar scripting technology to ASPs, which combine HTML scripts with portions of Java programs, among other technologies. Of these solutions, scripting has emerged as a popular Web-programming model for reasons related to performance and to the separation of logic from presentation:
Performance: Scripts are interpreted by an engine that is initialized once when the site is started and can continue serving requests until the server is shutdown. Also, most scripting engines cache the parsed scripts. Both of these advantages enable scripting solutions to significantly outperform CGI-based mechanisms.
Separation of logic and presentation: Scripts allow the application logic to be developed independently of the final presentation of a Web page. This significantly simplifies Web site development.
Even with the improvements described above, the cost of dynamically generating Web pages is still very high, which makes it very expensive for Web sites to serve millions of users with dynamic and personalized content. In an attempt to reduce the resources needed to service user requests and to better serve dynamic content, Web sites have resorted to caching.
Caching has emerged as the most important solution for reducing the cost of dynamically generating Web pages. The premise underlying caching is that in many cases, the content of dynamically generated pages does not change very frequently, thereby allowing the accessed pages to be cached. The server caches (locally stores for later retrieval) copies of such dynamically generated Web pages. Conventionally, as shown in FIG. 1 at S11, a client sends a Hypertext Transfer Protocol (HTTP) request for a Web page by, for example, clicking on a hyperlink or by specifying a Universal Resource Locator (URL). As shown at S12, the HTTP request is then received by the server, which then checks its cache to see if the response to the request (the entire requested Web page) is stored in the cache, as shown at S13. As called for by S18, if the requested page is indeed present in the cache and if the response page is still valid, the page is extracted from the cache and sent to the client, as shown at S17. If the entire requested page is not present in the cache or is present but invalid (stale), application logic and/or the Web page's script is executed, as shown at S14. Executing the application logic and/or script may require the server to access data sources such as databases or information feeds, as called for by step S15. Only thereafter may the requested Web page be dynamically generated and sent to the client, as specified in steps S16 and S17. A step of caching the just-generated full page in memory may also be carried out. This mechanism works very well as long as the dynamically generated pages can be cached efficiently (i.e., they are not invalidated very frequently), and the cost of servicing the page from the cache is less than the cost of re-generating the page again. As a result of efficient caching, a Web server uses fewer resources, especially Central Processing Unit resources to service a client's HTTP request. The ability to cache and to efficiently retrieve cached pages improves the server's performance (reduced response time) as well as its capacity to acceptably accommodate a greater number of users than it would otherwise have been able to serve without resorting to caching.
This type of caching is termed “full page caching”. This terminology reflects the nature of this form of caching wherein the cache memory contains complete HTML responses; that is, entire Web pages. Herein, an entire Web page corresponds to a single HTTP request. Note that this differs from a Web screen page displayed on a computer screen. Web screen pages may be composed of one or more Web pages independently requested by the logic that generates the display of Web screen pages on computer screens. Full page caching may improve a Web site's overall capacity to handle user traffic. However, this solution is limited in many cases, as the data sources for such dynamically generated pages may change very frequently or unpredictably, making it difficult to positively determine the current validity of the cached page. In many cases, moreover, a Web page refers to more than one data source. Since the granularity of caching is the entire page, changes to data from any one of the data source necessarily results in the invalidation of the entire page, even if the data originating from the other data sources has not changed. This problem is further exacerbated when one or more of the data sources changes very frequently. Indeed, if the Web page's data sources change very frequently, the cost of caching and frequently invalidating the cached entry may be greater than the cost of dynamically generating a new page to service each HTTP request. Because of these problems and the fear of serving stale pages, many Web sites have abandoned full page caching in favor of dynamically generating pages for each incoming request, despite the cost of doing so.
What is needed, therefore, are methods and systems for more efficiently servicing requests for dynamic content. What is also needed are methods and systems for efficiently caching dynamic content and for servicing incoming requests for such dynamic content at least partially by accessing and retrieving the cached content.